The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Many applications rely on multicast for communication amongst multiple nodes. In a group of n members, if a sender wants to send a packet to all other members, the sender can multicast the message once. This delivers the packet to all other group members. By contrast, with unicast, the sender would have to send (n−1) individual messages. Increasingly, multicast applications such as audio conferencing and multicast routing require secure delivery of packets.
There are many networking applications in which a network device, such as a router, switch, gateway, etc., can belong to an Internet Protocol (IP) multicast group. For example, sometimes routers in a group exchange control information where the integrity of that information is vital to the continued health of the attached network, the locally administered network, or large segments of the Internet. Typically, multicast groups comprise groups of routers, switches or other infrastructure elements in a network that receive packet data traffic that is sent using multicast protocols. To prevent non-members from using multicast traffic, the multicast traffic is encrypted using an encryption key that is known only to members of the multicast group.
This traffic can be secured with one or more data transforms, such as IPsec, as defined in Kent, S. and Atkinson, R. “Security Architecture for the Internet Protocol,” IETF Request for Comments (RFC) 2401, 1998. Before multicast groups can use IPSec to encrypt and authenticate packets on a scalable level, group members must be able to share and exchange encryption keys dynamically. The Multicast Security working group (MSEC) within the Internet Engineering Task Force (IETF) has proposed the Group Domain of Interpretation (GDOI) as a protocol to exchange keys within multicast groups. GDOI is described in IETF RFC 3547, which is available at the time of this writing at the RFC folder of the domain ietf.org on the World Wide Web. GDOI relies on a key server to generate encryption keys, then to push the keys down to group members. This helps salability and security by providing the ability to dynamically generate and refresh encryption keys.
A drawback of GDOI is that the key server itself must be manually configured ahead of time at each group member. A method for dynamically selecting a key server would further help scalability and reliability by allowing any group member to assume the role as key server in the event the exiting key server fails or becomes unavailable. While multicast group leader election protocol exist, any protocol used to dynamically select a key server must be secure. Specifically, such a protocol must guarantee the identity of the key server and the authenticity of messages it sends.
In GDOI, a key server authenticates individual group members using Phase 1 of the Internet Key Exchange protocol, which is described in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2409. Rather than proceeding to IKE Phase 2, however, GDOI group members enter a registration phase with the key server. At this point, the key server sends common IPSec encryption keys to all group members.
All the group members or potential group members in the network must know the network address of the GDOI key server before the process begins. In situations in which a key server fails, group members may need to elect a new key server from among themselves. To the same end, groups may want to communicate securely on an ad-hoc basis, that is, without the use of a pre-configured key server. However, past approaches have not provided an effective method to choose GDOI servers.
Further, some IP multicast applications are fault tolerant and must not be subject to a single point of failure. Examples of these protocols are IP routing protocols and redundancy protocols. IP routing protocols such as EIGRP and OSPF both use IP multicast to efficiently share routes with other routers on a LAN. If any EIGRP or OSPF router stops communicating with its peer routers on the LAN, the peer routers simply route around the failed router. Redundancy protocols such as HSRP, VRRP, and GLBP all use IP multicast traffic to negotiate which router(s) in a group will respond to queries. If the chosen router stops communicating, one of the other group members will take its place.
In any of these cases, if the network traffic was protected with IPsec keys served from a GDOI key server, and if the GDOI key server is on the failing router, then the group will not be able to operate after current IPsec keys expire. This risk of a GDOI key server providing a single point of failure is an impediment to its usage in these environments.
Prior work has been done in the field of dynamic election protocols. However, past approaches are not secure, and are not provided for the express purpose of choosing a key server. For example, Protocol Independent Multicast (PIM) is an example protocol that uses a leader election process to dynamically elect a Rendezvous Point. Other examples of prior work include:                1. I. Gupta et al., “A Probabilistically Correct Leader Election Protocol for Large Groups,” International Symposium on Distributed Computing, 2000;        2. Y. Huang et al., “Group Leader Election under Link-State Routing,” Dept. of Comp. Sci., Michigan State Univ., Proceedings of International Conference on Network Protocols;        3. M. Fischer et al., “Impossibility of Distributed Consensus with One Faulty Process,” J. Assoc. Comp. Machinery, vol. 32, no. 2, April, 1985, pp. 374-382;        4. T. Kostas et al., “Key Management for Secure Multicast Group Communication in Mobile Networks,” DARPA;        5. T. Kostas et al., “A Hierarchical Key Management System for Secure Multicast Group Communications in JTRS,” DARPA PTN # 869;        6. S. Vasudevan et al., “Secure Leader Election in Wireless Ad Hoc Networks,” University of Massachusetts Computer Science Technical Report 01-50, published 2001.        
Gupta et al. devised a group election protocol that worked correctly within a probability constraint. The protocol is too restrictive for GDOI, however, because it requires election participants to have some knowledge of other group members. It also requires each election participant to send some unicast messages to all other group members—this becomes unwieldy when RSA signatures are involved. The paper does reiterate a conclusion reached by Fischer et al. That a probabilistic guarantee of protocol correctness is the best one can reach when at least one process in the group may be faulty. Fischer et al. conclude that complete group consensus is impossible when even one person is faulty. Huang et al. examine group key server election as it applies to routers using link-state routing.
A method of discovering the location of a previously designated server using an IKE R_U_THERE message for “dead peer detection” (DPD) is described in Huang et al., “A Traffic-Based Method of Detecting Dead IKE Peers,” Internet-Draft, 2003.
Based on the foregoing, there is a clear need for a method and apparatus for electing a key server in a multicast group.
There is a specific need for a dynamic key server election method that is useful in GDOI multicast groups.